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(54) Methods, systems and apparatus for providing device identification within a network 

(57) A method and system for providing a device 
identification mechanism within a consumer electronics 
based audio/video network. Several consumer electron- 
ics products, e.g., television, VCR, tuner, set-top box (e. 
g. intelligent receiver/decoder. IRD), DVTRs, PCs, DVD 
players (digital video disk), etc., can be coupled within 
the network to communicate together via a standard 
bus, such as an IEEE 1394 serial communication bus 
(30). In one embodiment, the HAVI network offers 
unique advantages to consumer electronic vendors be- 
cause the architecture offers for the home network many 
of the advantages of existing computer system net- 
works. Specifically, interconnected devices can share 
resources and provide open, well defined APIs that al- 
low ease of development for third party developers. A 
global unique identifier (GUID) is associated with each 
device (e.g. 20) of the HAVI network. A low level driver 
(320) constructs a GUID list (510) of each device on the 
HAVI network. The order of the GUID entries in the 
GUID list (e.g., the index) matches the physical identifi- 
ers assigned to the devices by the 1394 serial bus (30). 
Although the physical identifiers can change on bus re- 
set, the GUID values are constant and are used for de- 
vice communication. Speed map (515) and topology 
map (520) information is maintained based on the phys- 
ical identifier information and therefore translations be- 
tween GUIDs and physical identifiers are efficiently per- 
formed when referencing speed map and topology in- 
formation for an application. 
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Description 

[0001] The present invention relates to the field of 
communication systems. More specifically, the present 
invention relates to methods, systems and apparatus for 
providing device identification within a network, such as 
may be used in equipment for home audio/video elec- 
tronics. 

[0002] Atypical home audiovisual equipment comple- 
ment includes a number of components, e.g., a radio 
receiver, a CD player, a pair of speakers, a television, a 
VCR a tape deck, etc. Components are connected to 
each other via sets of wires. One component is usually 
the central component of the home audiovisual system. 
This is usually the radio receiver, or the tuner/decoder. 
The control buttons and control switches are usually lo- 
cated on the front of the tuner and in many cases, some 
or all of these buttons and switches are duplicated on a 
hand held remote control unit. A user controls the home 
equipment by manipulating the buttons and switches on 
the front of the tuner, or alternatively, manipulating but- 
tons on the hand held remote control unit. 
[0003] As consumer electronic devices have become 
more capable and more complex, demand for the latest 
and most capable devices has increased. As new de- 
vices emerge and become popular, new devices are 
purchased by consumers and "plugged" into their home 
audiovisual systems. The new device is simply plugged 
into the system alongside the pre-existing, older devices 
(e.g., cassette tape deck, CD player, and the like). The 
new device is plugged into an open input on the back of 
the tuner, or some other device coupled to the tuner. The 
consumer (e.g., the user) controls the new device via 
control switches on the new device itself, or via a sepa- 
rate remote control unit for the new device. 
[0004] As the number of new consumer electronics 
devices for the home audiovisual system has grown and 
as the sophistication and capabilities of these devices 
have increased, a number of problems with the conven- 
tional paradigm emerge. One such problem is incom- 
patibility between devices in the home audiovisual sys- 
tem. In addition, where one device is much newer than 
another device additional incompatibilities may exist. 
For example, a new device might incorporate hardware 
(e.g., specific inputs and outputs) which enables more 
sophisticated remote control functions. This hardware 
may be unusable with older devices within the system. 
Another problem is the lack of functional support for dif- 
fering devices within an audiovisual system. For exam- 
ple, even though a television may support advanced 
sound formats (e.g., surround sound, stereo, etc.), if an 
older less capable tuner does not support such function- 
ality, the benefits of the advanced sound formats can be 
lost. Another problem is the proliferation of controls for 
the new and differing devices within the home audiovis- 
ual system. Each new device coupled to the audiovisual 
system often leads to another dedicated remote control 
unit for the user to keep track of and learn to operate. 



[0005] In view of the above, it is desired to provide a 
communication architecture in which consumer elec- 
tronics devices can be integrated. In so doing, the con- 
sumer electronics devices can offer and be expanded 

5 to include advanced communications and control func- 
tionality between themselves not heretofore offered. 
Within such communication architecture integrating 
consumer electronic devices ("a consumer's electronics 
network"), devices can communicate with each other 

to and control one another. 

[0006] The IEEE 1394 serial communication bus, ac- 
cording to the IEEE 1394 standard, assigns a 6-bit phys- 
ical identifier value (phy_id) to each device connected 
to the bus. The IEEE 1394 serial communication bus 

is uses this physical identifier to communicate with a de- 
vice coupled thereto. Whenever a new device is inserted 
onto the bus, or an existing device is removed from the 
bus, or both, a bus reset is caused. The bus reset initi- 
ates certain well known bus recovery communications 

20 and functions in accordance with the IEEE 1394 stand- 
ard, including the possible renumbering of the physical 
identifiers of the devices remaining on the IEEE 1394 
bus. That is to say, the physical identifiers assigned to 
devices on the IEEE 1394 bus are not persistent. 

25 [0007] However, it is also desired within the consumer 
electronics network that high level applications adopt 
abstract and persistent identifiers for devices coupled to 
the IEEE 1394 communication bus. Since many data 
structures (e.g., speed map and topology map) and 

30 communications channels are maintained and imple- 
mented within the IEEE 1394 standard using physical 
identifiers, a problem exists for high level applications 
that use a persistent identifier for each device but need 
to communicate with devices and/or require speed map 

35 and topology map information. What is needed is a 
mechanism and method operable within a consumer 
electronic network that provides an IEEE 1 394 commu- 
nication framework, but also provides high level appli- 
cations with a persistent identifier for devices coupled 

40 to the network. What is desired further is an efficient 
mechanism operable within a consumer electronic net- 
work that provides an IEEE 1 394 communication frame- 
work, but also provides high level applications with a 
persistent identifier for devices coupled to the network. 

45 [0008] Accordingly, the present invention provides an 
efficient mechanism and method operable within a con- 
sumer electronic network that provides an IEEE 1394 
communication framework and also provides high level 
applications with a persistent identifier for devices cou- 

50 pied to the network. The present invention provides 
such advantageous functionality utilizing global unique 
identifiers (GUIDs) assigned to each device of the con- 
sumer electronics network. A GUID map is constructed 
and maintained upon each bus reset that maps GUID 

55 values with physical identifier values. These and other 
advantages of the present invention not specifically 
mentioned above will become clear within discussions 
of the present invention presented herein. 
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[0009] A method and system are described herein for 
providing a device identification mechanism within a 
consumer electronics based audio/video network. With- 
in the network, several consumer electronics products, 
e.g., television, VCR, tuner, set-top box (e.g., intelligent 
receiver/decoder, IRD), DVTRs, PCs, DVD players (dig- 
ital video disk), etc., can be coupled to communicate to- 
gether via a standard bus (e.g., IEEE 1394 serial com- 
munication bus). This allows devices of the network to 
control one another and obtain information regarding 
one another. In one embodiment, the communication ar- 
chitecture used is the home audio/visual initiative (H AVI) 
format. The HAVI network offers unique advantages 
consumer electronic vendors because the architecture 
offers for the home network many of the advantages of 
existing computer system networks, namely intercon- 
nected devices can share resources and provide open, 
well defined APIs that allow ease of development for 
third party developers. HAVI offers extended interoper- 
ability. 

[0010] The present invention provides a mechanism 
whereby a global unique identifier (GUID) is associated 
with each device of the HAVI network. A low level driver, 
a link driver, constructs a GUID list including a GUID for 
each device on the HAVI network. The order of the GUID 
entries in the GUID list (e.g., the index) matches the 
physical identifiers assigned to the devices by the IEEE 
1 394 serial bus. Although the physical identifiers can be- 
come reassigned on bus reset, the GUID values are 
constant. Within the present invention, network-based 
applications use a device's GUID to communicate there- 
with. Speed map and topology map information is main- 
tained based on the physical identifier information. 
Therefore translations between GUIDs and physical 
identifiers are efficiently performed by the present inven- 
tion and are used for referencing speed map and topol- 
ogy information for an application program or other ob- 
ject. 

[0011] The 1 394 local bus architecture creates a dy- 
namic network within which a 1394 capable device can 
be inserted (e.g., hot insertion) at any time and be ready 
for use. Within the local bus system, a device is identi- 
fied with a 6-bit physical identification number (phy_id) 
which is assigned by the local bus upon a bus reset. The 
phy_id for a device can change as new devices are add- 
ed into or existing devices are removed from the net- 
work. To provide higher level applications with a persist- 
ing identifier for a given device, the GUID (global unique 
identifier) is employed by the present invention. The 
GUID is a unique 64 bit value that contains a vender 
identification number coupled with a chip series identi- 
fication number. The GUID is determined (according to 
IEEE 121 2 standards) when an IEEE 1 394 capable de- 
vice is manufactured. Because some bus information, 
such as speed map and topology map, are referenced 
by physical identifier values, the present invention pro- 
vides an efficient mechanism for presenting speed map 
and topology map information with respect to the corre- 



sponding GUID value for a device. 
[0012] A list of available devices in the network is in- 
formation that network-based applications generally re- 
quest periodically. The present invention generates and 

5 maintains a GUID list of all devices of the network and 
orders the GUIDs of the GUID list by their respective 
physical identifier values. In this manner, the index of a 
particular GUID within the GUID list is its physical iden- 
tifier and this index can be obtained and then used to 

10 access data from the speed map and topology map data 
structures which are constructed and maintained with 
respect to physical identifier values. For instance, if the 
speed between devicex (GU1D1) anddevicey (GUID2) 
is needed, the present invention locates the index val- 

1$ ues, indexl and index2, for GUID1 and GUID2 using the 
GUID list. Indexl and index2 are then used to access 
the speed map data structure and the desired speed da- 
ta is returned to higher level applications. Alternatively, 
the entire speed map or topology map can be presented 

20 to the higher level application along with the current 
GUID list and the application can perform the indexing 
for the desired data. 

[0013] The invention will now be described by way of 
example with reference to the accompanying drawings, 
25 throughout which like parts are referred to by like refer- 
ences, and in which: 

[0014] Figure 1 A il lust rates a physical port connect ion 
topology of an exemplary device configuration of the 
home audioA/isual initiative (HAVI) consumer electron- 

30 ics network in accordance with the present invention. 
[0015] Figure 1 B illustrates a local bus connection to- 
pology of the exemplary device configuration illustrated 
in Figure 1 A in accordance with the present invention. 
[0016] Figure 1 C illustrates a communication channel 

35 topology with respect to once device coupled to the 
HAVI network illustrated in Figure 1 A in accordance with 
the present invention. 

[0017] Figure 2 illustrates internal circuitry of an intel- 
ligent receiver/decoder device of the HAVI network of 

40 Figure 1A (acting as a full audioA/isual, FAV, node) in 
accordance with the present invention. 
[0018] Figure 3 illustrates a complement of software 
services made available by a full audio/visual (FAV) 
node of the HAVI network in accordance with the 

45 present invention. 

[0019] Figure 4 illustrates communication pathways 
within the HAVI software architecture in accordance with 
the present invention. 

[0020] Figure 5 A illustrates communication flow to the 
50 communication media manager (CMM) of the present 
invention from various software objects. 
[0021] Figure 5B illustrates communication flow to 
various software objects from the communication media 
manager (CMM) of the present invention. 
55 [0022] Figure 6 illustrates the IEEE 1 394 local bus in- 
terface (e.g., MPEG/MV Link) with CMM in the HAVI ar- 
chitecture. 

[0023] Figure 7 A and Figure 7B illustrates steps per- 
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formed within the HAVI architecture to implement mes- 
sage communication between devices. 
[0024] Figure 8 illustrates communication pathways 
between an application, a device control module (DCM), 
the CMM and a link driver in accordance with the present 
invention. 

[0025] Figure 9A is an illustration of a physical identi- 
fier indexed topology map data structure used by the 
present invention. 

[0026] Figure 9B and Figure 9C illustrate, respective- 
ly, one dimensional and two dimensional physical iden- 
tifier indexed speed map data structures as used by the 
present invention. 

[0027] Figure 1 0A shows a first exemplary device net- 
work configuration within the HAVI architecture. 
[0028] Figure 1 0B shows a second exemplary device 
network configuration within the HAVI architecture. 
[0029] Figure 11 A illustrates a GUID list as construct- 
ed by one embodiment of the present invention for the 
first exemplary device network configuration of Figure 
10A. 

[0030] Figure 11 B illustrates a GUID list as construct- 
ed by one embodiment of the present invention for the 
second exemplary device network configuration of Fig- 
ure 10B. 

[0031] Figure 12A illustrates a general GUID update 
status list constructed by a second embodiment of the 
present invention in response to the device network con- 
figurations of Figure 10A and Figure 10B. 
[0032] Figure 12B illustrates an "added" GUID update 
status list constructed by a second embodiment of the 
present invention in response to the device network con- 
figurations of Figure 10A and Figure 10B. 
[0033] Figure 12C illustrates a "removed" GUID up- 
date status list constructed by a second embodiment of 
the present invention in response to the device network 
configurations of Figure 10A and Figure 10B. 
[0034] Figure 13 is a flow diagram illustrating steps 
performed by the present invention for constructing a 
GUID list in response to a local bus reset. 
[0035] Figure 14 is a flow diagram illustrating steps 
performed by the present invention for constructing and 
communicating the GUID update status lists in response 
to a local bus reset. 

[0036] Figure 1 5A is a flow diagram illustrating the use 
of the GUID list in accordance with the present invention 
for sending a message to a device. 
[0037] Figure 15B illustrates the use of the GUID list 
to provide an index in accordance with the present in- 
vention for accessing the speed map to determine com- 
munication speed information. 

[0038] Figure 15C illustrates the use of the GUID list 
to provide an index in accordance with the present in- 
vention for accessing the topology map to determine to- 
pology information. 

[0039] Figure 15D illustrates the use of the GUID list 
to provide an index in accordance with the present in- 
vention for accessing the speed map to determine com- 



munication speed information where the application ref- 
erences the speed map. 

[0040] Figure 15E illustrates the use of the GUID list 
to provide an index in accordance with the present in- 
5 vention for accessing the topology map to determine to- 
pology information where the application references the 
topology map. 

[0041] In the following detailed description of the 
present invention, a method and system for providing 

io efficient device identification using a GUID list within a 
consumer electronics based audio/video network, nu- 
merous specific details are set forth in order to provide 
a thorough understanding of the present invention. 
However, it will be recognized by one skilled in the art 

is that the present invention may be practiced without 
these specific details or with equivalents thereof. In oth- 
er instances, well known methods, procedures, compo- 
nents, and circuits have not been described in detail as 
not to unnecessarily obscure aspects of the present in- 

20 vention. 

NOTATION AND NOMENCLATURE 

[0042] Some portions of the detailed descriptions 

25 which follow are presented in terms of procedures, 
steps, logic blocks, processing, and other symbolic rep- 
resentations of operations on data bits within a compu- 
ter memory (see Figure 2). These descriptions and rep- 
resentations are the means used by those skilled in the 

30 data processing arts to most effectively convey the sub- 
stance of their work to others skilled in the art. A proce- 
dure, computer executed step, logic block, process, 
etc., is here, and generally, conceived to be a self-con- 
sistent sequence of steps or instructions leading to a de- 

35 sired result. The steps are those requiring physical ma- 
nipulations of physical quantities. Usually, though not 
necessarily, these quantities take the form of electrical 
or magnetic signals capable of being stored, trans- 
ferred, combined, compared, and otherwise manipulat- 

40 ed in a computer system. It has proven convenient at 
times, principally for reasons of common usage, to refer 
to these signals as bits, values, elements, symbols, 
characters, terms, numbers, or the like. 
[0043] It should be borne in mind, however, that ail of 

^5 these and similar terms are to be associated with the 
appropriate physical quantities and are merely conven- 
ient labels applied to these quantities. Unless specifical- 
ly stated otherwise as apparent from the following dis- 
cussions, it is appreciated that throughout the present 

50 invention,, discussions utilizing terms such as "process- 
ing" or "computing" or "translating" or "calculating" or 
"determining" or "displaying" or "recognizing" or the tike, 
refer to the action and processes of a computer system, 
or similar electronic computing device, that manipulates 

55 and transforms data represented as physical (electron- 
ic) quantities within the computer system's registers and 
memories into other data similarly represented as phys- 
ical quantities within the computer system memories or 
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registers or other such information storage, transmis- 
sion or display devices. 

HAVI ARCHITECTURE GENERALLY 

[0044] Embodiments of the present invention are op- 
erable within a consumer electronics network of the 
home audio/visual initiative (HAVI) architecture. As- 
pects of the HAVI architecture network (e.g., "HAVI ar- 
chitecture") are discussed to provide a general frame- 
work in which embodiments of the present invention op- 
erate. 

[0045] HAVI is an architecture for inter-operating con- 
sumer electronics equipment devices adapted for the 
home network. The interoperability aspects define an 
architectural model that allows devices of any vendor to 
interwork within the home. A feature of the HAVI archi- 
tecture is the combination of a base set of generic device 
controls (a device control software module) with a meth- 
od to extend the base control protocol as new features 
and devices are deployed. 

[0046] The HAVI architecture supports a wide range 
of devices including intelligent receiver/decoders 
(IRDs), digital video tape records (DVTRs), video cas- 
sette recorders (VCRs), personal computers (PCs), dig- 
ital video disk players (DVDs), etc., communicating via 
a common messaging system. Figure 1 A illustrates the 
physical port-to-port connecting configuration 10a of an 
exemplary HAVI network. Several consumer electronics 
devices ("devices' 1 ) 12-24 are shown connected togeth- 
er with bus segments 30a-30f which couple ("plug into") 
to ports on the respective devices. In one embodiment 
of the HAVI architecture, the IEEE 1394 serial commu- 
nication bus standard is used as a local bus platform to 
provide the common messaging system. The IEEE 
1 394 serial communication bus carries both commands, 
status information and well as digital audio and digital 
video signals between devices. 

[0047] Figure 1B illustrates a logical bus configuration 
10b of the HAVI network of Figure 1 A. As shown in Fig- 
ure 1 B, all of the devices 1 2-24 of the HAVI network can 
be viewed as logically coupled to a common IEEE 1 394 
serial communication bus 30. Within this bus configura- 
tion 10b, peer-to-peer device communication is support- 
ed. For example : as shown in Figure 1C, any device 
(having appropriate capabilities), e.g., device 12, can 
send or receive communication packets from any other 
device in the HAVI network. In the example of Figure 
1 C , the set -top-box (e. g. , an I RD) can receive messages 
from or generate messages to any of the other devices 
14-24 of the exemplary HAVI network. 
[0048] The interoperability model in the HAVI archi- 
tecture provides for the following: 1 ) support for existing 
devices; 2) a default control model; 2) a means to extend 
the default control model when new devices or function- 
ality is brought to market; and 4) a common means for 
device representation (e.g., graphics user interfaces). 
To achieve the above, the HAVI architecture defines 
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three types of nodes in the home network. A base AV 
(BAV) node is defined for devices that already exist in 
the market (e.g., VCR 22 of Figure 1 A). An intermediate 
AV (IAV) node is defined for simple devices such as 

5 camcorders or DVTRs (e.g. , camera 1 4). A full AV (FAV) 
node is defined for devices of more resources, such as 
IRDs or smart televisions (e.g., set-top-box 12). An FAV 
node (or device) typically contains enough hardware to 
host control modules and to support application pro- 

io grams locally. The IAV devices and FAV devices com- 
municate by sending messages over the home network 
using a generic message passing system described 
more fully below. When new devices join the home net- 
work, they are recognized and added to a global name 

is database (registry). The registry holds information 
about their characteristics and provides a reference to 
a handler (e.g., communication point) for that device. 
Other devices and services are able to query the registry 
to locate a device and then, using the handler, can in- 

20 teract with the device. 

[0049] When a device is initially added to the home 
network, the system queries the device to ascertain its 
characteristics and capabilities. Once a device's char- 
acteristics are known, the architecture provides two 

2S methods of controlling it. The first method, level one in- 
teroperability, uses a predefined message set based on 
IEEE 1394 AV/C-CTS. All IAV and FAV nodes can. use 
this command set to access and control other devices, 
however, BAV nodes, because they are deployed before 

30 the architecture was defined, are controlled using lega- 
cy protocols. The level one interoperability provides a 
default level of control. The FAV nodes act as control 
nodes and create a local representation of the IAV node, 
known as a device control module (DCM), that provides 

35 an API used to send control commands to the device. 
[0050] Level two interoperability within the HAVI ar- 
chitecture goes farther and supports future added func- 
tionality and new devices. To achieve this, a particular 
device can carry within its ROM an override DCM that 

40 is uploaded from the IAV device, to the FAV device, and 
replaces the default DCM for the particular device. This 
override DCM not only contains the basic level one com- 
mand set for the particular device but also includes ven- 
dor specific commands to control advanced features of 

45 the device. This model allows the device to inform an- 
other object about its particular functionality. Since the 
override DCM may be loaded onto any vendor's FAV, 
the formal of the DCM is architecture-neutral. 
[0051] To allow one device to discover the capabilities 

50 of another device and to determine which command set 
to use with that device, a standard device description 
structure is provided called the self describing data 
(SDD) structure. The SDD data structure is extensible. 
It can be a small number of bytes describing the device 

55 type, e.g., TV, or VTR, etc. Alternatively, the SDD data 
structure can be a more complex structure also defining 
the override DCM and a graphical representation of the 
device. The graphical representation within the SDD da - 
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ta structure allows an FAV node to present a pictorial 
representation of the devices in the home network to us- 
ers. 

[0052] By defining the graphical representation in a 
sufficiently generic manner, a device's SDD graphical 
data can be used in any vendor's product to display (e. 
g., on a television or monitor within the network) a user 
interface for that device. This provides an enhanced lev- 
el of vendor interoperability and also allows a vendor to 
differentiate a product while maintaining within the gen- 
eral look and feel of the display device. The SDD also 
enables a control device (the FAV node) to present a 
general control user interface for all devices in the home 
network, irrespective of the differences in type and ven- 
dor. Self describing data (SDD) is described in copend- 
ing provisional application serial number 60/054,327, 
entitled "A Method and Apparatus for Including Self -De- 
scribing Information within Devices," filed July 31 , 1997 
and assigned to the assignee of the present invention. 
The above referenced provisional patent application is 
hereby incorporated by reference. 
[0053] Legacy devices are devices that were built be- 
fore the HAVI architecture or devices that select not to 
use the HAVI architecture. The HAVI architecture sup- 
ports Legacy devices by providing Legacy DCMs to pro- 
vide protocol conversions for Legacy devices. These 
Legacy DCMs can contain sufficient knowledge to allow 
them to support an existing 1 or 2 way control protocol 
and provide a specific control interface to the devices 
that conform to the HAVI architecture. A legacy DCM 
acts as a bridge between the Legacy and HAVI devices. 
This feature allows the HAVI architecture also to interact 
with any future device control protocols such as, for ex- 
ample, protocols being used for home energy manage- 
ment or security, etc. 

SET-TOP-BOX 12 OF FIGURE 2 

[0054] Any consumer electronics device can be pro- 
vided with the appropriate hardware to act as an FAV 
and thereby provide a platform for certain HAVI software 
(described below). For instance, the set-top-box 12 de- 
vice of the exemplary HAVI network of Figure 1 A con- 
tains special hardware components that provide an op- 
eration platform for software components ol the HAVI 
architecture. Another example of an FAV is a digital tel- 
evision having the required hardware resources to sup- 
port HAVI software. Certain aspects of the present in- 
vention, described below, are discussed in terms of 
steps executed on a computer system (e.g., processes 
400, 700, 800, 850, 900a, 950a, 900b and 950b). Al- 
though a variety of different computer systems can be 
used with the present invention, an exemplary general 
purpose computer system is shown in the set-top-box 
FAV of Figure 2. 

[0055] Set-top-box 12 of Figure 2, in addition to hav- 
ing a video/audio receiver (decoder) unit 106 and MPEG 
unit 107 also includes an internal address/data bus 100 



for communicating information, one or more central 
processors 1 01 coupled with the bus 1 00 for processing 
information and instructions, a volatile memory 102 (e. 
g., random access memory RAM) coupled with the bus 

s 100 for storing information and instructions for the cen- 
tral processor 101 and a non-volatile memory 103 (e.g., 
read only memory ROM) coupled with the bus 100 for 
storing static information and instructions for the proc- 
essor 101 . Set -top-box 12 can also optionally include a 

10 data storage device 104 ("disk subsystem") such as a 
magnetic or optical disk and disk drive coupled with the 
bus 1 00 for storing information and instructions. Also in- 
cluded in the set -top-box 12 is a bus interface unit 108 
for interfacing with the local bus 30 (e.g., an IEEE 1 394 

is serial bus). Set -top-box 1 2 can operate under a variety 
of different operating systems (e.g. ; Windows operating 
system, DOS operating system, Macintosh O/S), but in 
one embodiment the Aperios operating system is used. 

20 HAVI SOFTWARE ARCHITECTURE 

[0056] In one embodiment, the software of the HAVI 
architecture can be broken into three APIs (AVOS, in- 
teroperability and application). The AVOS API is a low 

25 level system API that abstracts the common operating 
system services, e.g., threads, communications, and 
memory. Interoperability APIs are abstractions of com- 
mon device control models and provide a basic repre- 
sentation model and a means to extend the control mod- 

30 el with vendor specific commands. The application API 
is a high level API for applications including interactive 
TV applications, and in one embodiment is based on the 
DAVIC API set including the Motion Hypermedia Expert 
Group (MHEG) interactive application engine. 

35 [0057] Figure 3 illustrates the software architecture 
200 used in the HAVI architecture in more detail. The 
architecture 200 contains several generic components 
to provide abstractions of common facilities in the home 
network. A communication media manager 250 is pro- 

40 vided and this component abstracts from the underlying 
transport network. In the case of the IEEE 1394, the 
communication media manager 250 maintains and gen- 
erates information regarding the speed maps 515 (Fig- 
ure 8) and topology maps 520 which are used by em- 

45 bodiments of the present invention. A DCM Manager 
270 is also provided that is responsible for identifying 
and creating generic DCMs 230 for level one interoper- 
ability. The DCM Manager 270 also hosts override DC- 
Ms uploaded from devices or other sites. A Graphics 

50 Management unit 220 is provided which supplies gener- 
ic graphics APIs that applications and DCMs can use to 
present user interface information. 
[0058] A Stream Manager 335 of Figure 3 is used to 
determine the most effective route for AV streams within 

55 the home network. A data format manager is included 
within the Stream Manager 335 and is responsible for 
providing conversion of AV streams to and from various 
formats as they flow between devices in the home net- 
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work. These operations are described below with refer- 
ence to Figure 7A and Figure 7B. A Messaging Manager 
212 supports a generic messaging mechanism that al- 
lows devices to locate and interact with other devices in 
the home network. A communications media manager 
(CMM) 250 is a media dependent entity in the HAVI soft- 
ware architecture 200. The CMM 250 provides abstract 
services to other HAVI components or application pro- 
grams in the HAVI network. It also provides media spe- 
cific transport mechanisms for actual data communica- 
tion among various devices in the home network. The 
CMM 250 is responsible for compiling new GUID status 
updates upon a local bus reset. It is appreciated that 
each physical communication media contains its own 
CMM to serve the above purposes. As one example, the 
CMM 250 for the IEEE 1394 serial bus is described 
herein further below. 

[0059] The Event Manager 214, the Registry 21 6 : the 
Stream Manager 335 and the Initialization Manager 210 
of Figure 3 are described separately further below. 
[0060] Figure 4 illustrates a data flow diagram 305a 
with the HAVI software architecture 200 including an in- 
terface with the local bus HAL layer 330 for local bus 30. 
In diagram 305a, the top layer is an application program 
layer ("application layer") 220 which can communicate 
with a function control module (FCM) layer 314 having 
AV/C command. The application layer 220 resides with- 
in a FAV and can also communicate with device control 
modules (DCMs) 230 and with the Registry 216. The 
application layer 220 communicates with a Stream Man- 
ager 335. The DCMs 230 are controlled by the DCM 
manager 270 which can communicate with the Event 
Manager 214. The Event Manager 214 communicates 
with the CMM 250. The Stream Manager 335 allows 
communication between the application layer and the 
CMM 250. The AV Messenger unit 212 also communi- 
cates with the CMM 250. The CMM 250 provides an in- 
terface with the local bus interface 330 via a link driver 
unit 320. The link driver unit 320 is responsible for com- 
piling new GUID lists upon a local bus reset. Higher level 
applications are located with block 310 and lower level 
applications within block 312. A subset of this commu- 
nication diagram 305a is illustrated in Figure 8. 
[0061] Figure 5A is a diagram 340a that illustrates 
communication channels that are available for commu- 
nicating to the CMM 250. The application layer 220 com- 
municates with the CMM 250 to obtain bus generation 
information, to obtain the GUID list, to obtain the speed 
map 515 and to obtain the topology map 520. The fol- 
lowing APIs are used to perform these functions: get- 
GUI DList(); getBusGeneration(); getSpeedMap(); and 
get Topology Map(). The ilink transportation adaptation 
module, TAM, 212b communicates with the CMM 250 
for asynchronous requests and asynchronous respons- 
es. The digital l/F controller 335a communicates with the 
CMM 250 for asynchronous requests, asynchronous re- 
sponses, channel allocations, channel deallocations, 
bandwidth allocations and bandwidth deallocations. 



The Stream Manager 335 utilizes GUID information to 
establish point to point communications via the digital I/ 
F controller 335a. The digital l/F controller 335a com- 
municates with the CMM 250 using the following APIs: 

s allocateChannelO; deallocateChannel(); allocateBand- 
width(); and deallocateBandwidth(). The isochronous 
data transceiver 230 is a DCM and communicates with 
the CMM 250 using the following APIs: isoOpen(); iso- 
Close(); isoAttach(); isoDetach(); and isoControl(). 

w [0062] Figure 5B is a diagram 340b that illustrates 
communication channels that are available for commu- 
nicating from the CMM 250 to other objects. The CMM 
250 communicates bus reset indications to the Event 
Manager 214. The CMM 250 also communicates status 

is information regarding the set of current devices on the 
local bus 30 including information as to which devices 
are added and which devices have been removed from 
the local bus 30 since the last GUID list was constructed. 
The CMM 250 also communicates bus reset information 

20 to the ilink TAM 21 2b as well as GUID information, asyn- 
chronous receive, and isochronous receive. This same 
information is also communicated from the CMM 250 to 
the isochronous data transceiver module 230. Informa- 
tion regarding which devices are coupled to the local bus 

25 30 is also communicated from the CMM 250 to the digital 
l/F controller 335a. 

[0063] Figure 6 illustrates an exemplary interface 360 
between the CMM 250 and the local bus 30 for IEEE 
1394 interfacing. A 1394 Bus Manager 370 is also 

30 shown. The CMM 250 contains a copy of the speed map 
51 5 and the topology map 520 (described further below) 
and and IEEE 1394 Bus Manager 370 contains control/ 
status registers (CSRs). The isochronous resource 
manager 372 contains information regarding the bus 

35 master identification and the available channels and 
bandwidth for communication via isochronous registers 
(CSRs). The node controller 374 contains a configura- 
tion ROM as well as node control registers (CSRs). 
Units 250, 372 and 374 constitute the serial bus man- 

40 agement unit 370. Unit 370 communicates with 1394 
HAL interface (l/F) layer 330. The transaction block 378 
processes read/write/lock transactions, tracks pending 
transactions and controls retry protocol operations with 
a busy/timeout register. Data transmission takes place 

45 within the link layer 380 and the l/F (CFR) unit 385. 

DCM 230 AND DCM MANAGER 270 

[0064] A description of the DCM 230 and the DCM 
50 manager 270 of Figure 3, as well as other aspects of the 
HAVI software architecture 200 are described in co- 
pending US patent application serial 

number , entitled "A Home Audio/ 

Video Network with Two Level Device Control", by R. 
55 Lea and A. Ludtke, filed concurrently herewith, attorney 
docket No. SONY-50L2278, assigned to the assignee 
of the present invention and hereby incorporated herein 
by reference. 
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THE COMMUNICATIONS MEDIA MANAGER 250 

[0065] The CMM 250 (e.g., for the IEEE 1 394 bus) of 
Figure 4 provides two levels of APIs. One is the high- 
level API that interacts with other HAVI components to 
offer abstract services such as topology map 520 and 
speed map 515 as well as generating HAVI related 
events. The other level of APIs is the low-level API that 
provides a basic transport mechanism for both asyn- 
chronous and isochronous data transfers. Normally, 
high-level APIs are available to any HAVI entity or ap- 
plications residing locally on this same node, while the 
low-level APIs presents the primary interface to the 
IEEE 1 394 bus 30 so that specific protocols can be built 
on top of the CMM 250. To access high-level APIs, the 
HAVI message system (e.g., AvMessenger 212) is 
used, whereas access to low-level APIs can be accom- 
plished through direct calls to the CMM 250. 
[0066] The messaging used to access high-level APIs 
through HAVI message system is done using a format 
having a multi-byte selector followed by function de- 
pendent parameters. The function selector determines 
which service to use from the CMM 250, and the param- 
eters section provides all required parameters for the 
specified function. To invoke low-level APIs, only the pa- 
rameters section is necessary. 

[0067] The IEEE local bus 30 is a dynamically config- 
urable network. After each bus reset, a device can have 
a complete different physical identifier (phy_id) than it 
had before the bus reset. If a HAVI component or an 
application has been communicating with a device in the 
HAVI network it generally desires to continue the com- 
munication after a bus reset even though the device may 
have a different physical identifier. To identify a device 
uniquely regardless of frequent bus resets, the present 
invention provides the Global Unique ID (GUID) which 
is used by the CMM 250 and other HAVI entities. A GUI D 
is a multi-bit number (e.g., 64-bits in one implementa- 
tion) that is composed of 24 bits of node-vendor identi- 
fication and 40 bits of chip (series) identification. While 
a device's physical identifier may change constantly, its 
GUID is permanent within the HAVI architecture. The 
CMM 250 of the present invention makes device GUID 
information available for its clients using a GUID list dis- 
cussed further below. 

[0068] The CMM 250 abstracts the underlying device 
interconnection mechanism, providing a common set of 
API's to describe the capabilities of the bus architecture. 
In one embodiment, the CMM concept is driven by the 
IEEE 1 394 bus model, but is sufficiently abstract to pro- 
vide a general service for interconnection management. 
The CMM 250 provides APIs for 4 four basic concepts. 

(1) Channel: a channel is a logical data connection that 
a bus can support. For technology such as IEEE 1 394, 
this maps directly to hardware support for multiple chan- 
nels. For technology that only supports a single data 
connection, then this degenerates to a single channel. 

(2) Bridge: a bridge is a connection between two bus 



4 

technologies and allows channels to span different bus 
technologies. (3) Node: a node is a physical endpoint 
for a channel and corresponds to a unit or subunit in the 
HAV architecture. (4) Bandwidth: this is a metric of how 
5 much data can be carried on a bus at any one time. 
Bandwidth can be assigned to channels to support the 
required data rates for whatever data the channel is de- 
livering. 

[0069] For those bus protocols which do not support 
io these concepts, the results of API calls to their CMMs 
have limited results. For example, if a particular bus 
technology does not support multiple simultaneous data 
transfer actions, then it most likely reports only a single 
"channel," even though it does not really support chan- 
ts nels. The CMM 250 maps transactions to the channel 
model. 

[0070] There is one CMM 250 for each physical inter- 
face (e.g. 1394, Control A1, TCP/IP) on a FAV node. 
Because there can be more than one kind of CMM 250, 
20 and because there can be many of them in existence, 
each CMM 250 has a module_type attribute attached to 
its entry in the Service Registry 216 database. The def- 
inition of this attribute can be as follows: 

2S module_type = busManager 

module_data = {1394, Control A1, TCP/IP, etc.} 
These bus types will have numeric identifiers de- 
fined for them. 

30 [0071] Each CMM 250 contains the general set of 
API's for bus management, as well as protocol -specific 
API'S. If a particular bus technology supports features 
that are above and beyond the general model, then it 
can subclass the CMM base class and add the new 

3S functionality. For example, the 1394 CMM 250 allows 
access to the 1 394-specific bus attributes such as the 
isochronous resource manager. Those clients who are 
1 394-aware, and need such capabilities, can go through 
the 1394 CMM 250. 

40 [0072] One of the advanced features the 1394 bus 
provides to the HAVI architecture is its support for dy- 
namic device actions such as hot plugging (device in- 
sertion or power up) and unplugging (device removal or 
power down). To fully support this to the user level, high 

45 level software clients need to be aware of these envi- 
ronment changes and the present invention provides 
this information. The CMM 250 works with the Event 
Manager 214 to detect and announce these dynamic 
bus changes using device status tables (Figure 12A, 

so Figure 12B, Figure 12C). Since any topology change 
within 1 394 bus will cause a bus reset to occur, the CMM 
250 is informed of these changes and notifies the Event 
Manager 21 4 of these changes along with the informa- 
tion about devices that have disappeared as well as 

55 those that have become available. The Event Manager 
214 then distributes the related event to all interested 
HAVI entities or applications that previously established 
the proper call back handlers. 
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[0073] There are two basic types of events that are 
generated from the CMM 250 to support dynamic up- 
dating of available devices in the network. One is 
NEW_DEV1CE which indicates a new device, and the 
other is GONElDEVICE, indicating a device has been 
removed. To increase efficiency, the CMM 250 gener- 
ates device status tables with this information. Whenev- 
er a device is added or removed from the network, a bus 
reset is generated and CMM 250 finds and passes a 
status table of new/gone devices to the Event Manager 
214 if the Event Manager 214 has requested such serv- 
ice. Since NEW_ DEVICE or GONEJDEVICE also indi- 
cates the occurrence of a bus reset, the Event Manager 
214 may also create a BUS_RESET event based on the 
above information. It should be noted that all these 
events are generally "local," which means that the Event 
Manager 214 does not generally send/broadcast such 
events to any other nodes. 

[0074] The CMM 250 also provides topology, speed 
maps, and other environment descriptions to its clients. 
The topology map 520 (Figure 9A) depicts the connec- 
tivity among physical devices. Within the present inven- 
tion, it can be used to build a human interface that helps 
the user understand how devices are connected and 
how certain features may be used. The speed map 515 
(Figure 9B, Figure 9C) provides information on the pos- 
sible maximum speed that can be used for data trans- 
mission between any two devices in the network. Speed 
maps provide information about the connectivity and 
performance of sections of the HAV network. It can be 
used to analyze the current connection scheme and give 
the user helpful suggestions for improving the perform- 
ance of devices by rearranging the connections. If at- 
tributes such as the topology map 520 cannot be auto- 
matically generated, then a dialog with the user may be 
required. When a topology request is made to a CMM 
for a protocol that does not support automatic topology 
detection, the request can trigger such a dialog. After 
interacting with the user to determine how its devices 
are connected, the CMM returns the requested informa- 
tion. 

[0075] Topology map 520 and speed map 515 may 
change constantly because their organization (e.g., da- 
ta order) is based on the physical identifiers of the de- 
vices on the network and these values can become re- 
assigned due to the allowed dynamic insertion or remov- 
al of devices. To identify the right "version" for these 
maps, a bus generation number may be used. Newer 
bus generation values signify the change of bus config- 
uration. It may also be used to check if a pending oper- 
ation is "stale". Since transactions between devices re- 
quire the existence of those devices, it is possible that 
a pending transaction has not yet completed and one or 
more devices involved have gone away. When this hap- 
pens, a new bus generation number will be generated 
and the related process can check against this new gen- 
eration number to make proper clean up for the stale 
transaction. 
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[0076] Bus generation number, topology map 520, 
and speed map 515 remain unchanged between bus re- 
sets. To improve efficiency, the CMM 250 may optionally 
cache them internally and keep them updated only when 
5 bus reset occurs. 

[0077] Another feature of the IEEE 1 394 bus 30 is its 
capability to send timing -critical stream through its iso- 
chronous channels. To send data in isochronous mode, 
channel number and proper bandwidth need to be allo- 
10 cated from the bus. The CMM 250 provides such serv- 
ices to allocate/deallocate channel numbers and band- 
width for its clients. It is also responsible to restore these 
resources for its clients right after each bus reset so that 
any existing isochronous data transaction will not be dis- 
1$ rupted because of the unavailability of these resources. 
[0078] The CMM 250 also provides a transport mech- 
anism to actually transfer the data, which is part of low- 
level services. There are two types of data transactions 
with I EEE 1 394 bus 30. One is asynchronous, the other 
20 isochronous. Typical asynchronous transfer includes 
quadlet/block write, quadlet/block read, and lock oper- 
ations. Typical isochronous data transfer normally in- 
volves allocating channel/bandwidth, opening iso- 
chronous data port, attaching data buffer(s), and acti- 
os vating data transfer. These services provide a funda- 
mental transport mechanism for a 1 394 based HAVI sys- 
tem being functional. 

[0079] The following APIs are provided by IEEE 1 394 
specific CMM 250 within the present invention: 

30 

1) CMM::enrollComeNGo() 

Status: enrollComeNGo(ObjectlD oid, (void*) (*) 
callback_handler) 

This command is used by the Event Manager 214 
35 to get a list of new and removed devices when bus 
reset occurs. The Event Manager 214 enrolls such 
request to the CMM 250 to get the service. The pa- 
rameter oid is the caller's object identifier and 
callback_handler is the callback function provided 
40 by the caller. The caller (typically Event Manager 
214) enrolls its OID and a callback handler to the 
CMM 250 so that when bus reset occurs, the CMM 
250 invokes the callback function with a list of de- 
vices (device status table) that are either new or 
45 gone. 

2) CMM::getGUIDList() 

Status: CMM 250::getGulDList(GUID *guid) 
This command gets the GUID for all active devices 
so in the network. The parameter guid is a pointer to a 

the GUID list. 

3) CMM::getBusGeneration() 

Status: CMM::getBusGeneration(uint32 *bus_en_ 
55 number) 

This command gets the current local bus generation 
number from the network. The parameter 
bus_en_n umber is the current bus generation 
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number. 

4) CMM: :getSpeedMap() 
Status: CMM::getspeedMap(uint32 bus_en_number 
u_char *spd_map) 5 
This command gets the speed map 515 which is as- 
sociated with the bus generation number specified. 
The parameter bus_en_number is the current bus 
generation number, spd_map is a pointer to the 
speed map 515 io 

5) CMM::getTopologyMap() 

Status: CMM::getTopologyMap(uint32 bus_en_ 
number, uint32 * top_map) 

This command gets the topology map 520 that is as- is 
sociated with the bus generation number specified. 
The parameter bus_en_number is the current bus 
generation number and top_map is a pointer to an 
array of integer numbers, each representing a selL- 
I D packet from a 1 394 node. 20 

6) CMM::atlocatechannel() 

Status: CMM:: allocateChannel(uint32 chan_no) 
This command allocates a channel specified by 
chan_no. If chan_no is all ones (Ox FFFFffff), any 25 
channel available will be allocated and returned. 
The parameter chan_no is a channel number to be 
allocated. 

7) CMM::deallocatechannel() 30 
Status: CMM::deallocateChannel(uint32 chan_no) 
This command deallocates a channel specified by 
chan„no. The parameter chan_no is the channel 
number to be deallocated. 

35 

8) CMM::allocateBandwidth() 

Status: CMM:: allocateBandwidth(uint32 band- 
width) 

This command allocates the bandwidth specified by 
bandwidth. The parameter bandwidth is the band- 40 
width to be allocated. 

9) CMM::deallocateBandwidth() 

Status: CMM::deallocateBandwidth(uint32 band- 
width) 45 
This command deallocates the bandwidth specified 
by bandwidth. The parameter bandwidth is the 
bandwidth to be deallocated. 

10) CMM::asyncWrite() so 
Status: CMM::asyncWrite(GUID guid ; u_int64 
remote_offset, u_char *data, uint32 data size, 
uint32 pk_format) 

This command sends an asynchronous write re- 
quest to the remote device, which is identified by ss 
guid. The parameter guid is the target device's 
GUID, remote_offset is the target device's memory 
offset, data is a pointer to data to be sent, data_size 



is the size of data (in byte) to be sent and pk_format 
is the format to use, either quadlet or block for data 
transfer. 

11) CMM::asyncRead() 

Status: CMM::asyncRead(GUID guid, u_int64 
remote_offset, u_char *data, uint32 data_size, 
uint32pk_format) 

This command sends a asynchronous read request 
to the remote device, and returns the data read 
back. The parameter guid is the target device's 
GUID, remote_offset is the target device's memory 
offset, data is the pointer to data to be received, 
data_size is the size of data (in byte) to readback 
from remote site, and pk_format is the format to use, 
either quadlet or block for data transfer. 

12) CMM::asyncLock() 

Status: CMM::asynclock(GUID guid, u_int64 
remote_offset, u_char *old_data u_char 
*new_data, uint32 data_size uint32 exLcode) 
This command makes a lock operation on the spec- 
ified address in the remote device. The parameter 
old_data is used for compare and swap operation. 
The parameter guid is the target device's GUID, 
remote_offset is the target device's memory offset, 
old_data is the pointer to old data, new_data is the 
pointer to the new data, data_size is the size of data 
(in byte) to be sent, and ext_code is the extended 
code to be used for the lock operation 

13) CMM::isoOpen() 

Status: CMMI::isoOpen(uint32 direction, uint32 
bus_speed, uint32 bandwidth, uint32 *port-no) 
This command opens an isochronous port for either 
sending or receiving operation. The actual port 
opened is returned in port_no. The parameter direc- 
tion is the sending or receiving operation, 
bus_speed is the requested bus speed, bandwidth 
is the maximum bandwidth to be used, and porLno 
is the port number successfully opened 

14) CMM::isoClose() 

Status: CMM: :isoClose(uint32 port-no) 
This command closes the port specificed. The pa- 
rameter port_no is the port number to be closed 
Close the port specified. 

15) CMM::isoAttach() 

Status: CMM ::ios Attach (uint32 porLno, u_char 
^buffer) 

This command attaches a user buffer to the speci- 
fied port. The parameter porLno is the port number 
to be used and buffer is the data buffer. 

16) CMM::isoDetach() 

Status: CMM::iosDetach(uint32 port-no, u_char 
'buffer) 
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This command detaches a user buffer from the spe- 
cified port. The parameter port_no is the port 
number to be used and buffer is the data buffer. 

17) CMM::isoControl() 

Status: CMM::isoControl(uint32 chan, uint32 trig- 
ger) 

This command controls the actual data transfer. It 
starts immediately or on some synchronization bit. 
The parameter chan is the channel to be used for 
the transfer and trigger is the method to use to start 
the traffic. 

[0080] In addition to the basic four abstractions dis- 
cussed above (Node, Channel, Bridge and Bandwidth), 
the following concepts describe the bus model. The to- 
pology map 520 is a connected graph which mirrors the 
physical connections between nodes on the network. 
For IEEE 1 394, the map is generated automatically. For 
other protocols, manual assistance from the user may 
be required. The overall system topology is an amalga- 
mation of individual bus topologies. The generation 
number provides a way to measure whether a pending 
operation is "stale." Since transactions between devices 
depend on being able to access those devices, it is pos- 
sible that a pending transaction has not yet completed 
and one or more of the devices involved have gone 
away. When this happens, any modules that care about 
the bus generation react accordingly. 
[0081] The generation value is based on the ability to 
determine that the bus configuration has changed. For 
protocols such as IEEE 1394, the generation is critical 
because of hot plugging support. For others, if hot plug- 
ging support can be simulated, then the generation 
number can be managed as well. If no hot plugging sup- 
port can be created, then the generation number will al- 
ways default to "1," meaning that the bus has not 
changed since the host system was initialized. A bus 
can allow a certain maximum number of nodes (devices) 
to be connected and individually addressable at any giv- 
en time. At any given time, the CMM 250 is informed of 
how many devices are currently attached and address- 
able (number of nodes) 

[0082] As described more fully below, the CMM 250 
provides bus reset or change notification for buses that 
support dynamic connection. After a bus reset is detect- 
ed, this module assigns new "opaque" ID values to all 
devices that have just appeared, determines what de- 
vices have gone away, invokes the DCM Manager 270 
module to create new DCMs, and posts a bus_change 
notification event to the Event Manager 214, which no- 
tifies all registered clients about the reset. In accordance 
with the present invention, it also provides enough in- 
formation for the clients to determine what devices have 
disappeared and about any newly discovered devices. 
The CMM 250 works with the Event Manager 214 to de- 
tect and announce dynamic bus changes that do not 
trigger system-wide interrupts or events, thus bringing 
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some of the advantages of 1 394 technology to other bus 
protocols. 

[0083] The CMM 250 provides clients with the physi- 
cal topology map 520, in a manner that does not require 

s clients to have bus-specific knowledge. The topology 
map 520 can be generated automatically for those con- 
trol protocols which support it, or can be generated with 
user interaction and stored for later use for those proto- 
cols that do not support automatic generation. Because 

10 topologies can be quite diverse, the CMM 250 provides 
a topology iterator function similar to that of the Service 
Registry 216. This function allows clients to visit each 
node in a connect ion -specific manner, with a simple API 
to move forward or backward through the net. The client 

is can determine simply that this device is connected to 
that one, which is connected to that one, etc. For clients 
who simply need to know about all devices in a topology, 
with no concern for connectbn patterns, the GUID list 
is provided. Other API's allow the query to determine if 

20 agivenmodulelD (the identification of a DCM which rep- 
resents a physical device) is represented in the topolo- 
gy, etc. 

[0084] The CMM 250 also provides logical connection 
information. This is a connection model that specifies 

25 data flow sources and sinks. The API allows inquiries 
such as "given DCM module ID X, tell caller all of the 
DCMs that are listening to it." Other variations on this 
inquiry model include the ability to ask for all currently 
active streams of a particular data type (e.g. MPEG, 

30 SD), etc. 

EVENT MANAGER 214 

[0085] The Event Manager 214 of Figure 4 is de- 

35 signed to support a one-to-many model of communica- 
tion. It is built above the basic messaging system 212. 
Objects register interest in events which are then deliv- 
ered to their event call back entry. For instance, objects 
interested in device status information register special 

40 call back handlers for this information with the Event 
Manager 21 4. Objects can attach event filters to the call- 
back entries that allow them to filter out events that they 
are not currently interested in. For example an object 
may register for all events from display devices, but filter 

45 out those display devices it is not currently using. 

[0086] Events are broadcasted by the messaging sys- 
tem 21 2 and delivered to all objects that have registered 
an interest in the event. To achieve this, objects register 
their interest with their local Event Manager 214. The 

50 messaging system delivers events to all known Event 
Managers 214 which are then responsible for ensuring 
that registered objects are informed about events. Fil- 
ters can be attached to Event Managers 214 to allow 
objects to filter out the events as they arrive. This gives 

ss an object the flexibility to register interest in an event, 
but have control over how each event is used. For ex- 
ample a filter could be used to specify that event X is 
only of interest if it occurs after event Y The Event Man- 
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ager 214 tracks fitters and provides an API that allows 
applications and DCMs to build sophisticated event fil- 
tering chains. 

STREAM MANAGER 335 

[0087] The Stream Manager 335 of Figure 4 provides 
an API for configuring end-to-end isochronous ("stream- 
ing") connections. Connections maybe point-to-point or 
utilize unbound sources or sinks. The responsibilities of 
the Stream Manager 335 include: configuration of con- 
nections; requesting allocation of network resources; 
maintenance of global connection information; and sup- 
port of high-level stream operations such as plug type 
checking, splicing and bridging. 

[0088] A Stream Manager 335 runs on each FAV 
node. The interface is based on the IEEE 1212 unit di- 
rectory model and the IEC 6 1883-FDIS plug model 
(HAVI refers to units and subunits as devices and func- 
tional components respectively). Point-to-point connec- 
tions and broadcast connections are supported. In IEEE 
1394, a broadcast connection is one in which either the 
source or sink is not specified when the connection is 
requested. Streams do not cross transport boundaries, 
but bridge devices can be used to feed one stream into 
another. Streams originate and terminate at functional 
components (rather than devices). For IEEE 1394 net- 
works, the Stream Manager 335 is responsible for allo- 
cating PCRs (plug control registers) and requesting bus 
bandwidth. A standard naming scheme is used for 
stream types, transport types and transmission formats. 
The stream type and transport type naming schemes 
are specified by HAVI, transmission formats are the 
FMT/FDF values used in IEC 1883 Common Iso- 
chronous Packets. 

[0089] A stream type identifies a media representa- 
tion, this can be a data format (for digital media) or signal 
format (for analog media), e.g. CD audio, NTSC. A 
transport type identifies a transport system, two exam- 
ples are IEC 1883 (for connections running over 1394) 
and "internal" (for connections internal to a device). A 
transmission format identifies the data transmission pro- 
tocol used to send a stream type over a transport type. 
For IEC 1883, the transmission format corresponds to 
the FMT and FDF fields in the Common Isochronous 
Packet (CIP) header. 

[0090] A stream as used by the Stream Manager 335 
is based on the isochronous data flow model from IEC 
1883 with three differences. The first difference is that 
streams do not restrict the number of sources and so 
can have multiple sources provided the transport sup- 
ports this form of connectivity, for example, a UDP 
"event" stream being fed by many processes. The sec- 
ond difference is that an IEEE 1 394 data flow starts at 
a device output plug and ends at a device input plug, 
while a stream typically starts at a functional component 
output plug, goes to a device output plug, then a device 
input plug, and ends at a functional component input 



plug. The final difference is that streams are typed, e.g., 
for each stream there is an associated stream type iden- 
tifying the data 

[0091] The following summarizes the properties of 
5 streams: 1 ) a stream is associated with a globally unique 
stream identifier; 2) a stream is carried over a single 
channel; 3) output functional component plugs ("plugs") 
and input plugs can join a stream (this can also be stated 
as "connect to the channel"); 4) a channel can be con- 
10 nected to zero or more output plugs and zero or more 
input plugs; 5) an input plug can join at most one stream; 
6) an output plug can join many streams (for example a 
functional component output plug attached to several 
device output plugs); 7) a stream can be created with 
15 no output plug, but no data will flow over the stream until 
an output plug has joined: and 8) the upper limit on the 
number of plugs that can be connected to a channel is 
transport type dependent. 

[0092] A stream can be viewed as a set of plugs. The 

20 following rules apply to connections within a device. 
Functional component input plugs can have only one 
connection (from a functional component output plug or 
a device input plug). Functional component output plugs 
can have many connections (to functional component 

25 input plugs and/or device output plugs). Device output 
plugs can have only one connection from a functional 
component output plug. Device input plugs can have 
many connections to functional component input plugs. 
[0093] There are three procedures for adding or re- 

30 moving plugs from this set: 1) point-to-point procedure 
(Connect, Disconnect); 2) broadcast-out procedure 
(Start Broadcast, Stop Broadcast): and 3) broadcast -in 
procedure (Tap, Untap). Connect creates a point-to- 
point connection between two plugs (e.g., a connection 

35 from an output plug to the channel and a connection 
from the channel to the input plug); it adds an output 
plug and an input plug to the stream (assuming neither 
are already members). Start Broadcast creates a 
"broadcast -out" connection (e.g., a connection from an 

40 output plug to the channel); it adds an output plug to the 
stream (assuming it is not already a member). Tap cre- 
ates a "broadcast-in" connection (e.g., a connection 
from the channel to an input plug); it adds an input plug 
to the stream (assuming it is not already a member). Dis- 

45 connect, StopBroadcast and Untap drop the connec- 
tions created by Connect, StartBroadcast, and Tap re- 
spectively. They remove plugs (if not used by other con- 
nections within the stream). 

[0094] Streams allow the overlaying of connections 
50 as described in IEC-1883, e.g., a plug may have many 
connections (both point-to-point and broadcast) to the 
channel used by the stream. Following the connection 
semantics of I EC- 1883, the Stream Manager 335 de- 
cides when to remove a plug from a stream by examin- 
es ing the plug's point-to-point connection counter and a 
broadcast flag (which indicates whether or not the plug 
participates in a broadcast connection) A plug is re- 
moved from a stream when the point-to-point connec- 
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tion is 0 and the broadcast flag is false. The underlying 
network resources used for a stream are allocated when 
the first plug is added to the stream and released when 
the last plug is removed. In the case of a channel con- 
nected to several output plugs, the manner in which the 5 
resulting data flow is delivered is transport type depend- 
ent and the Stream Manager 335 does not guarantee 
that all input plugs will receive data in the same order. 
[0095] The Stream Manager 335 maintains a map of 
all stream connections within the home network. This 10 
map includes internal connections (those within devic- 
es) and external connections (those over transport sys- 
tems). The Stream Manager 335 builds the Global Con- 
nection Map upon initialization, after bus reset, and pe- 
riodically while running (in case new connections have is 
been added or removed by non-HAVI applications). 
[0096] An AV network can take on many topological 
configurations, depending on how the user has made 
the connections between devices. For example, an 
IEEE 1 394 bus allows any topology except a loop. The 20 
Stream manager 335 of Figure 3 works with the CMM 
250 to provide services to assist with routing data from 
source to destination. This can include many nodes in 
between. In the event that the source and destination 
involve different data types, or are separated by a "data 2s 
type barrier, p it will work with a data format manager and 
Service Registry 216 to handle automatic or requested 
data translation services as well. Some routing can be 
performed automatically, based on the capabilities pro- 
vided by the underlying bus architecture. For example, 30 
the topology of the IEEE 1394 bus can be precisely de- 
termined, and therefore automatic routing between di- 
rectly-connected 1394 devices can be achieved. How- 
ever, other connection mechanisms can require interac- 
tion with the user, either to assist the user with making 35 
well-known connections or to have the user indicate to 
the controlling software how devices are connected. 
[0097] One of the most significant attributes of the 
IEEE 1394 technology is isochronous data flow. Addi- 
tional services provided by the Stream manager 335 for *o 
this kind of data include buffer allocation and manage- 
ment. Buffer management includes the provision of a 
consistent notification mechanism to let the client know 
when data is available, so that it can be processed. 
While isochronous data is flowing into a client, various 45 
memory buffers will be filled with that data. As each buff- 
er is filled, the client may want to know so that it can 
handle the data acquisition process from that point for- 
ward. 

[0098] In addition, buffer management can be simpli- so 
fied for clients by having the appropriate service mod- 
ules partition memory in a manner that is optimized for 
the data being captured. For example, the client can al- 
locate one large space of memory, then specify that it 
will be used for capturing a stream of video data. It is 55 
possible that the optimum configuration of this memory 
is to separate it into scan line- or frame-sized segments, 
so the client can receive one complete line or frame of 
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video on each notification. Raw audio and MIDI data will 
likely have different optimum segment sizes. Such serv- 
ices require close cooperation between the Route and 
Data Format Managers, and various service modules. 
[0099] Refer to Figure 7A and Figure 7B where an ex- 
ample process 400 is shown for setting up a data flow. 
A client wants to establish a connection between two 
devices, so at step 410 it calls to establish an external 
connection of one of the two DCMs that represent those 
devices. It passes the modulelD of the other device's 
DCM as a parameter. At step 415, the DCM that was 
called then calls the Stream Manager (SM) 335 to assist 
with making the connection. It passes both the source 
and destination DCM module IDs as parameters. At step 
420, the SM 335 analyzes the source and destination 
IDs, finds that they are in different nodes (this step may 
be carried out by some other entity before invoking the 
DFM). At step 425, the SM 335 asks the CMM 250 of 
the source node for the topology map 520 for its net- 
work. At step 430, the SM 335 analyzes the topology 
map 520 to find the destination node. 
[01 00] At step 435 of Figure 7 A, if the destination node 
is on the topology map 520, then no transport protocol 
translation is necessary and step 445 is entered directly. 
If the destination node is not on the map, then at step 
475 (Figure 7B) the SM 335 asks the Registry 216 for 
the module with the destinationID, to look at the 
1ransmission_protocor attribute, or alternatively, it gets 
the bus manager ID for that module/node. At step 480, 
the SM 335 then finds a transmission protocol service 
module, and sets up the conversion process (see sep- 
arate example for these details). At step 485, the above 
process is repeated if multiple transports need to be 
bridged. 

[0101] At step 445 of Figure 7A, the SM 335 analyzes 
the connection paths to find the best route. If no deter- 
ministically optimal path can be determined, then a best 
guess is accepted. This is done for the entire path from 
source to destination, including intermediate or cross- 
network boundaries. All necessary connections are 
made (in the case of dynamic buses such as 1394). At 
step 450, the SM 335 analyzes the input data formats 
for source and destination. At step 455, if the formats 
are the same, then no format conversion is necessary. 
At this point (465) the data flow route 400 is complete. 
[0102] If conversion is necessary, then at step 460, 
the SM 335 asks the Registry 216 for the appropriate 
format converter based on input and output format and 
sets up the conversion process. Note that several con- 
verters can be chained together to achieve the final re- 
sult from original source to desired destination formats. 
The data flow route 400 is then complete. 

SERVICE REGISTRY 216 

[01 03] The Service Registry 21 6 of Figure 4 provides 
a mechanism to locate devices and services that are 
available in the HAV network. Since all devices and 
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services are represented by objects, the Service Reg- 
istry 216 allows any object to advertise itself. Typically, 
resident on an FAV, the Service Registry 16 contains in- 
formation on local service objects, remote service ob- 
jects and local and remote devices. The Service Regis- 
try 216 operates by providing an API that allows objects 
to register their unique identifier, a name, and a set of 
attributes that define their characteristics including con- 
nection point information. Any object wishing to locate 
a particular service or device object can do so by que- 
rying the Service Registry 21 6 for the appropriate DCM. 
[0104] Attributes associated with an object may be 
static or dynamic, and can be subsequently changed if 
desired. Attribute querying is carried out by specifying 
a set of required attributes which then returns a list of 
objects that match the required attributes. Identifiers re- 
turned as a result of a query are not guaranteed to be 
valid. This can happen in one of two ways. First, if a 
device has posted its availability into the registry and 
then has gone off-line. If the query arrives between the 
time of going off-line and actually withdrawing the serv- 
ice from the registry, then the identifier will be stale. Sec- 
ond, if a query returns a set of identifiers, the results may 
be held within an object for an extended period of time. 
When they are finally used, it may be that the service 
has been withdrawn from the registry. 
[0105] The Service Registry 216 is a distributed serv- 
ice. Any object that registers with its local Service Reg- 
istry will be accessible via any other instances of the 
Service Registry 216 in the HAV network. Each Service 
Registry 216 works with others to ensure that entries 
are replicated or available when required. However, for 
both performance and resource reasons, it is often the 
case that an item registered in one registry will not be 
visible in another, although the system will try to ensure 
this. This implies that a simple query to a local Service 
Registry 216 may return the local registry's view of the 
global state. It will always be possible to cause a remote 
query to be carried out on behalf of the query to ensure 
that the global state of the system is queried explicitly 
[0106] Queries to the Service Registry 21 6 return ob- 
ject identifiers usable as end point for message commu- 
nication. These identifiers may refer to DCMs, services, 
or any other entity in the system accessible via the mes- 
saging system. The format of the queries allows both 
sophisticated queries that iterate over the global registry 
or simple queries that are confined to a local registry. 

MESSAGING 212 

[0107] The messaging system 212 of Figure 3 is de- 
signed to provide a reliable high level messaging service 
that supports the transport of 4 different types of mes- 
sages. (1) Commands: these flow between objects in 
the system and are used to access functionality. When 
the target object is a device then these messages are 
sent by a DCM and contain actual device control mes- 
sages. (2) Events: events are used as a general purpose 



asynchronous communication mechanism that allows 
both devices and service modules to communicate in- 
formation. Although the messaging system 212 is used 
to carry these events they are under the control of the 

5 Event Manager 214 which uses a broadcast feature of 
the communications infrastructure to send events to 
those who are interested. (3) Errors: errors are similar 
to events except errors are delivered to the source of 
the command that caused the error and then broadcast. 

10 (4) Status: these messages are designed to be used in 
response to a query. 

[01 08] The message system 21 2 provides both a syn- 
chronous and an asynchronous send allowing services 
to operate in either mode. The messaging system 212 
is defines a minimum capability to allow interoperability at 
the message level. This includes the format of identifi- 
ers, the format of message identifiers and the format of 
messages. 

[0109] The following illustrates an exemplary imple- 

20 mentation. Local identifiers are 56 bit and are guaran- 
teed to be unique to a particular host. Network identifiers 
are 128 bits and consists of a 64 bit node identifier, an 
8 bit node type and the 56 bit local identifier. The generic 
format for remote messages is a 4 octet type field fol- 

25 lowed by a parameter block. This is referred to as the 
message payload. The mechanism to support local 
messaging is implementation dependent and what is re- 
quired is that local identifiers guarantee consistent de- 
livery of the message payload. Remote messaging 

30 takes a message payload and encapsulates it in a net- 
work message. The network message format is header 
plus message payload. The network message header 
is 96 bits and consists of a reserved 6 bit field, a 2 bit 
packet type, a 56 bit local identifier and a 32 bit message 

35 identifier. Depending on the actual transport mecha- 
nism, this remote message packet will be encapsulated 
in a transport specific message, e.g. IP or IEEE 1394. 

INITIALIZATION MANAGER 210 

40 

[0110] The Initialization Manager 210 of Figure 3 is 
used to bring an IAV or FAV node up to initial status. In 
the case of an IAV node this manager 210 will initialize 
the messaging 212, event 214 and registry 216 service. 
45 For the FAV node it will also invoke initialization routines 
for the DCM manager 270 and any pre-loaded services. 

APPLICATION INTERFACE 220 

50 [0111] The Application Interface 220 of Figure 4 is a 
proxy to the messaging system 212 and provides a 
means for applications to access services and devices 
in the AV architecture. The Application Interface 220 is 
not necessarily a component of the AV architecture, but 

55 rather a means of allowing an arbitrary application to 
work with the AV architecture. The mechanism used to 
provide the application object depends on the location 
of the application and the execution environment it uses. 
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Applications can be downloaded from external services 
provided and made resident (e.g., instantiated) within 
an intelligent device (FAV) of a HAVI network. An Appli- 
cation so downloaded can query the Service Registry 
216 to determine connection points for controlling de- 
vices of the HAVI network. 

[0112] There are 3 general cases. The first case is lo- 
cal application running native on the FAV node. These 
types of applications are designed to make use of the 
native OS and hardware features of the FAV node. They 
are created externally to the AV architecture and use the 
application interface to gain access to the AV architec- 
ture services. The exact means to achieve this are sys- 
tem dependent, but a library linked into the application 
is a typical approach. 

[0113] The second case is local application running 
above the FAV interoperability language run-time. In this 
case : the AV architecture uses an architecture neutral 
run time to support level 2 interoperability. This run time 
can also be used to support arbitrary applications written 
to be hosted on the run time. Such applications are man- 
aged by the AV architecture and will typically access the 
AV services via a run time supplied calling mechanisms. 
[0114] The third case is remote application. These ap- 
plications may be running on other devices in the home 
network such as home personal computers (PCs). 
These applications need access to the AV architecture 
and do so by using the basic message passing model 
of the system. This implies that these applications need 
a partial implementation of the messaging infrastructure 
resident on their host node. 

GRAPHICS MANAGER 218 

[0115] The Graphics Manager 218 of Figure 3 pro- 
vides a high level API for the management of the user 
interface (Ul) associated with devices. The role of the 
Graphics Manager 218 is to support the User Interface 
model by providing a graphics API that is semantically 
rich. Low level graphics APIs are generally located close 
to graphic displays and are used by the high level graph- 
ics API to provide and support the Ul. 

DEVICE IDENTIFICATION PROCESSES 

[0116] Figure 8 illustrates a portion 305b of the HAVI 
communication architecture and illustrates an applica- 
tion layer 220, a device control module 230 for a partic- 
ular device 20, the CMM 250, the link driver layer 320, 
an electronic device 20 coupled to the IEEE 1394 com- 
munication bus 30 and the speed map 515 and topology 
map 520 data structures. The location of the CMM 250 
and the link driver layer 320 in the overall architecture 
of HAVI is shown in interface 305a of Figure 4. 
[0117] As described above, the present invention al- 
lows high level software programs (e.g., the application 
layer 220) to reference devices using a persistent iden- 
tification scheme. Namely, multi-bit persistent Global 
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Unique Identifier numbers (GUIDs) are assigned to 
each device and contain a vendor portion and a chip 
series portion. In one embodiment, a 64-bit number is 
used as the GUID. Figure 8 illustrates an exemplary 
s communication path whereby the application layer 220 
issues a command to cause device 20 to perform some 
predefined action (e.g., to start "playing - some media). 
The initial command from the application layer 220 in- 
eludes an abstract identifier (e.g., B VCR1 B ) of the DCM 
10 230 object and also the action to be done (e.g., "play"). 
[0118] The DCM 230 of Figure 8 converts the abstract 
object name into a GUID that matches device 20 and 
issues another command including the GUID and the 
action, "play, " to the CMM 250. The CMM 250 contains 
is a GUID list 510 in accordance with the present inven- 
tion. The GUID list 510 is a listing of GUIDs in order of 
their associated physical identifications (for each re- 
spective device). Therefore, the GUID list 510 of the 
present invention functions as an efficient physical iden- 
20 tification to GUI D translator and a GUID to physical iden- 
tification translator. The GUID list 510 is updated by the 
link driver 320 each time a bus reset event is detected. 
[0119] The CMM 250, using the GUID list 510, con- 
verts the GUID received from the DCM 230 into the cor- 
2S responding physical identifier for device 20. The CMM 
250 then passes a message to the link driver layer 320 
including the action command, "play," and the physical 
identifier corresponding to device 20. The link driver lay- 
er 320 interfaces with the local bus 30 using the physical 
30 identifier thereby communicating the action command, 
"play," to the device 20. The speed map 515 and topol- 
ogy map 520 are present for other aspects of the present 
invention described further below. 
[0120] Figure 9 A, Figure 9B and Figure 9C illustrate 
35 exemplary speed map 51 5 and topology map 520 data 
structures. The entries of the speed map 51 5 and topol- 
ogy map 520 data structures are organized (e.g., or- 
dered or indexed) based on the physical identifier of the 
devices. The mechanisms for generating the speed map 
40 51 5 and the topology map 520 data structures are well 
known within the IEEE 1 394 standard. 
[0121] Figure 9A illustrates an exemplary topology 
map 520 data structure used by the present invention. 
This data structure 520 includes a respective entry (of 
45 entries 522a-522n) for each of the n devices coupled to 
the local bus 30. The first field 524 of each entry corre- 
sponds to the device's physical identifier as assigned by 
the local bus layer 330. As shown in Figure 9A, the en- 
tries 522a-522n are ordered according to their physical 
so identifier, e.g., physicalJDO, physical_ID1 , ... 
physicalJDn. The folbwing fields 526, 528, 530 for 
each entry specify port information for each physical 
port of the device. The port information indicates the 
physical connection of that port to another port. Using 
55 this port information, one can determine the manner in 
which the n devices of the local bus 30 are physically 
coupled together in the HAVI network. Topology map 
520 data structures of the format shown in Figure 9A 
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are well known in the art and are re-generated upon 
each local bus reset. 

[0122] Figure 9B illustrates an exemplary one-dimen- 
sional speed map data structure 515a used by the 
present invention. This data structure 515a includes a 
respective entry (of entries 531a-531n) for each of the 
n devices coupled to the local bus 30. The first field 532 
of each entry corresponds to the device's physical iden- 
tifier as assigned by the local bus layer 330. As shown 
in Figure 9B, the entries 531 a-531 n are ordered accord- 
ing to their physical identifier, e.g., physicalJDO, 
physical_ID1, physicalJDn. Field 534 indicates in- 
formation pertinent to the communication protocol (in- 
cluding communicate rate) available for the device. 
Speed map 51 5a data structures of the format shown in 
Figure 9B are well known in the art and are re-generated 
upon each local bus reset. 

[0123] Figure 9C illustrates a two dimensional speed 
map 515b data structure used by the present invention. 
Speed map 515b is a matrix where each matrix entry 
546 conveys information regarding the communication 
speed between referenced devices (e.g., devices refer- 
enced by phy_id n and phy_id 2). The speed map 51 5b 
has a first index 542 and a second index 544, both being 
ordered according to their physical identifiers. Speed 
map 515b data structures of the format shown in Figure 
9C are well known in the art and are re-generated upon 
each local bus reset. 

[0124] Figure 10A illustrates an exemplary HAVI net- 
work 560a having five devices coupled to the local bus. 
Device 562 has a physical identifier (0) and a GUID(Y); 
device 564 has a physical identifier (1 ) and a GUID(Z); 
device 566 has a physical identifier (2) and a GUID(I); 
device 568 has a physical identifier (3) and a GUID(J) 
and device 570 has a physical identifier (4) and a GUID 
(X). Each of the GUID values is unique and persistent. 
The physical identifier values for the devices of Figure 
10A can become reassigned after a local bus reset. 
[0125] Figure 11 A illustrates the resulting GUID list 
510a compiled by the present invention based on the 
exemplary HAVI network 560a of Figure 10A. The GUID 
list 51 0a contains five entries, one for each device of the 
HAVI network. As shown, the GUID values in the GUID 
list 510a are ordered, e.g., GUID(Y); GUID(Z); GUID(I); 
GUID(J); and GUID(X), according to the corresponding 
physical identification values, 0, 1, 2, 3 and 4, respec- 
tively. In one embodiment, GUID list 510a is compiled 
by the link driver 320 and stored in computer readable 
memory. 

[0126] Figure 10B illustrates another exemplary HAVI 
network 560b having six devices coupled to the local 
bus. Network 560b is similar to network 560a except de- 
vice 566 is removed and devices 572 and 574 are add- 
ed. In network 560b, device 572 has a physical identifier 
(1) and a GUID(U) and device 574 has a physical iden- 
tifier (5) and a GUID(N). Some of the physical identifier 
values between Figure 10A and Figure 10B have been 
reassigned due to a local bus reset. The reassigned 



physical identifiers for the remaining devices are as fol- 
lows: device 562 has physical identifier (0), device 564 
has physical identifier (3), device 568 has physical iden- 
tifier (4) and device 570 has physical identifier (2). Each 
5 of the GUID values is unique and persistent for all de- 
vices. 

[0127] Figure 11 B illustrates the resulting GUID list 
510b compiled by the present invention based on the 
exemplary HAVI network 560b of Figure 10B. The GUID 

10 list 51 Ob contains six entries, one for each device of the 
HAVI network 560b. As shown, the GUID values in the 
GUID list 510b are ordered, e.g., GUID(Y); GUID(U); 
GUID(X); GUID(Z); GUID(J) and GUID(N), according to 
the corresponding physical identification values, 0, 1 , 2, 

15 3, 4 and 5, respectively. In one embodiment, the GUID 
list 510b is compiled by the link driver 320 and stored in 
computer readable memory. 

[0128] Figure 12A illustrates a GUID status table 630 
generated by the CMM 250 of the present invention 

20 each time a local bus reset is generated. The GUID sta- 
tus table 630 includes entries 632a-632g regarding (1 ) 
which devices remain connected to the local bus 30 
since the last GUID list 510 was compiled, e.g., after a 
local bus reset, (2) which devices have been just re- 

2s moved and (3) which devices have been just added 
since the last GUID list 510 was compiled. A first field 
632 represents the GUID value of the device and an as- 
sociated field 634 represents the current status of that 
device. Figure 12A represents an exemplary table 630 

30 generated by CMM 250 as a result of the exemplary con- 
figurations of Figure 10A and Figure 10B. As shown in 
table 630, the devices having GUID(Y), GUID(X), GUID 
(Z), and GUID(J) remain after the local bus reset. How- 
ever, the devices having GUID(U), and GUID(N) have 

35 been added after the local bus reset and the device hav- 
ing GUID(I) was removed after the local bus reset. In 
one embodiment, the GUID table 630 is compiled by the 
CMM 250 and stored in computer readable memory. 
[01 29] Figure 1 2B illustrates a subset status table 650 
generated by the CMM 250 which contains entries 
652a-652b indicating only which devices have been 
added to the local bus 30 since the last GUID list 510 
was compiled. Likewise, Figure 12C illustrates a subset 
status table 660 generated by the CMM 250 which con- 

45 tains entries (662a) indicating only which devices have 
been removed from the local bus 30 since the last GUID 
list 510 was compiled. In one embodiment, the GUID 
tables 650-660 are compiled by the CMM 250 and 
stored in computer readable memory. Device status ta- 

so bles 630, 650 and 660 are forwarded to objects within 
the HAVI architecture that establish callback handlers 
within the CMM 250 to receive this information. 
[0130] Figure 1 3 illustrates a flow diagram 700 of the 
steps performed by the link driver 320 of the present in- 

55 vention for compiling a current GUID table 510 in re- 
sponse to a local bus reset. After a local bus reset, phys- 
ical identifiers of devices are reassigned by the local bus 
30. At step 710, if a local bus reset is reported to the link 



16 

BNSDCCID: <EP 0932275A2J_> 



31 



EP 0 932 275 A2 



32 



driver 320, then step 71 5 is entered. At step 715, current 
GUID list is erased and the link driver 320 determines 
the number of devices, n, that are currently coupled to 
the local bus 30. A number ot well known mechanisms 
can be used to implement step 7 1 5. At step 720, a coun- 
ter is set to zero. At step 725 : the link layer 320 issues 
a request to the device coupled to the local bus 30 and 
having the physical identifier corresponding to the coun- 
ter value. The request is for the GUID value of this de- 
vice. At this point, the link layer 320 is unaware which 
device this is. 

[0131] At step 730, the link layer 320 receives the re- 
turn GUID value from the device with the physical iden- 
tifier of the counter value and places this GUID value 
into a next entry of the current GUID list 510 (the entry 
position also corresponds to the counter value). At step 
735, the counter is incremented by one. At step 740, a 
check is made if the counter is equal to n (the maximum 
number of devices on the local bus). If not, then step 
725 is entered again to continue compiling the current 
GUID list. If so, then at step 745, the link layer 320 for- 
wards the CMM 250 a copy of the current GUID list 51 0. 
It is appreciated that physical identifiers are assigned by 
the local bus 30 from 0 to (n-1) values. After process 
700, a current GUID list 510 like those shown in Figure 
1 1 A and Figure 1 1 B is compiled. 

[0132] Figure 14 illustrates a flow diagram 800 of the 
steps performed by the Link layer 320 and the CMM 250 
of the present invention for compiling the device status 
tables 630, 650, 660 in response to a local bus reset. 
As discussed above, process 700 generates a current 
GUID list 510 in response to a local bus reset and pass- 
es the current list to the CMM 250. At step 820, the cur- 
rent GUID list is received and the last GUID list received 
by the CMM 250 is retained and marked as a "previous" 
GUID list. At step 825, the CMM 250 compares the en- 
tries of the previous GUID list and the current GUID list 
510 and generates GUID table 650 based on the new 
GUID values that are present in the current GUID list 
510 but not in the previous GUID list. Any object within 
the HAVI architecture that previously established a call- 
back handler with the Event Manager 214 for the infor- 
mation of table 650 is sent a message including the sta- 
tus information of table 650. 

[0133] At step 830, the CMM 250 compares the en- 
tries of the previous GUID list and the current GUID list 
510 and generates GUID table 660 based on any GUID 
values that are no longer present in the current GUID 
list 510 but were present in the previous GUID list. Any 
object within the HAVI architecture that previously es- 
tablished a callback handler with the Event Manager 
214 for the information of table 660 is sent a message 
including the status information of table 660. Optionally, 
at step 830, the information from tables 660 and 650 can 
be combined with the GUID values that are common to 
both the previous and current GUID lists thereby gener- 
ating table 630. At step 835, the CMM 250 erases the 
previous GUID list and uses only the current GUID list 



510. By performing process 800, the CMM 250 and the 
link layer 320 of the present invention eliminate the bur- 
den from higher level application programs of tracking 
which devices are on the local bus while providing the 
s high level application programs with device status infor- 
mation. 

[0134] Figure 15A illustrates a flow diagram 850 of 
steps performed by the present invention for translating 
GUI D values into physical identifications using the GUID 
10 list 51 0 passed to the CMM 250. At step 855, an appli- 
cation program issues a command to control a device 
(x) and this command is received by the DCM of the de- 
vice(x). At step 860 : the DCM issues a command to the 
CMM 250 including device(x)'s GUID value which is 
is known to the DCM. At step 865, the CMM 250 deter- 
mines the index (e.g., entry order) of the device(x)'s 
GUID within the GUID list 510. This value is the physical 
identifier of device(x). At step 870, the CMM 250 issues 
a command to the link driver layer 320 including device 
20 (x)'s physical identifier and an action command. The link 
driver layer 320 then commands device(x) using the re- 
ceived physical identifier. Using process 850, high level 
applications do not need to be aware of a device's phys- 
ical identifier but can use the constant GUID value. 
25 [0135] Figure 15B illustrates a flow diagram 900a of 
steps performed by the present invention for accessing 
speed map information with respect to two devices giv- 
en their GUIDs. At step 910, an application layer issues 
a command to determine the communication speed 
30 supported between device(x) and device(y). The re- 
quest includes the GUIDvaluesfordevice(x)and device 
(y). At step 915, the CMM 250 receives this command 
and the GUID values. The CMM 250 translates the 
GUID values into two physical identifiers based on the 
35 index of the GUIDs within the GUID list 51 0. At step 920, 
the CMM 250 then accesses (e.g., indexes) a two di- 
mensional speed map data structure 515b with the ob- 
tained two physical identifiers. The speed map thereby 
returns the proper speed information. At step 925, the 
40 CMM 250 forwards the determined speed information 
to the requesting application layer. 
[01 36] Figure 1 5C illustrates a flow diagram 950a of 
steps performed by the present invention for accessing 
topology map information with respect to a device given 
45 its GUID value. At step 955, an application layer issues 
a command to determine the topology of a device(y). 
The request includes the GUID value for device(y). At 
step 960, the CMM 250 receives this command and the 
GUID value. The CMM 250 translates the GUID value 
50 into a physical identifier based on the index of the GUID 
within the GUID list 510. At step 965, the CMM 250 then 
accesses (e.g., indexes) a topology data structure 520 
with the obtained physical identifier. The topology map 
thereby returns the proper topology information for de- 
55 vice(y). At step 970, the CMM 250 forwards the deter- 
mined topology information to the requesting application 
layer. 

[0137] Figure 1 5D illustrates a flow diagram 900b of 
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steps performed by the present invention for accessing Claims 
speed map information with respect to two devices giv- 
en their GUIDs. The difference between process 900b 1. 
and 900a (Figure 15A) is that the application program 
determines the speed information, not the CMM 250. At 5 
step 980, an application layer issues a command to de- 
termine the communication speed between device(x) 
and device(y). At step 982, the CMM 250 receives this 
command and forwards the current GUID list 51 0 as well 
as a copy of the speed map 515b (or pointers to these 
data structures) to the application program. At step 984, 
the application program translates the GUID values of 
the two devices into two physical identifiers based on 
the index of the GUIDs within the GUID list 510. The 
application program then accesses (e.g., indexes) the 
two dimensional speed map data structure 51 5b with the 
obtained two physical identifiers. The speed map there- 
by returns the proper speed information. 
[0138] Figure 15E illustrates a flow diagram 950b of 
steps performed by the present invention for accessing 
topology information with respect to a device given its 
GUID. The difference between process 950b and 950a 
(Figure 15B) is that the application program determines 
the topology information, not the CMM 250. At step 990, 
an application layer issues a command to determine the 
topology information of device(y). At step 992, the CMM 
250 receives this command and forwards the current 
GUID list 51 0 as well as a copy of the topology map 520 2. 
(or a pointer to this data structure) to the application pro- 
gram. At step 994, the application program translates 
the GUID value of thedevice(y) into a physical identifier 
based on the index of the GUID within the GUID list 510. 
The application program then accesses (e.g., indexes) 
the topology data structure 520 with the obtained phys- 
ical identifier. The topology map thereby returns the 
proper topology information. 

[01 39] It is appreciated that by providing the GUID list 
510, the present invention allows high level applications 
to utilize persistent device identifiers (GUIDs) to refer- 
ences devices. Upon a bus reset, the high level devices 
are not burdened with the reassign ments of physical 
identifiers that are done at the local bus level. The GUID 
list 510 is particularly efficient by organizing the ordering 
of GUI Ds to conform to the physical identifier value. This 
reduces memory required to store the GUID list 510 and 
creates an efficient index mechanism. 
[0140] The preferred embodiments of the present in- 
vention, a method and system for providing efficient de- 
vice identification using a GUID list within a consumer 
electronics based audio/video network, are thus de- 
scribed. While the present invention has been described 
in particular embodiments, it should be appreciated that 
the present invention should not be construed as limited 
by such embodiments, but rather construed according 
to the below claims. 55 
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A method of providing device identification to ac- 
cess information within a network, said method 
comprising the steps of: 

a) constructing a list of global unique identifiers 
(GUIDs) wherein each GUID identifies a unique 
device of said network and wherein said con- 
structing orders GUIDs within said list of GUIDs 
according to their associated physical identifier 
values, wherein said physical identifier values 
are assigned by a local bus of said network; 

b) receiving a request originating from an ap- 
plication program to determine a communica- 
tion speed value corresponding to a device of 
said network wherein said request includes a 
first GUID corresponding to said device; 

c) using said list of GUIDs to determine a first 
index value corresponding to a position of said 
first GUID within said list of GUIDs; and 

d) referencing a speed map data structure with 
said first index value to obtain said communi- 
cation speed value, wherein said speed map 
data structure is organized based on physical 
identifiers. 

A method as described in Claim 1 further compris- 
ing the step of e) communicating said communica- 
tion speed value to said application program and 
wherein said network is a network of the home au- 
dio/visual initiative (HAVI) architecture and wherein 
said local bus is of the IEEE 1394 standard. 

A method as described in Claim 1 further compris- 
ing the steps of: 

f) in response to a local bus reset, renumbering 
physical identifiers of devices of said network 
that are coupled to said local bus; 

g) rebuilding said speed map data structure 
based on renumbered physical identifiers of 
step f); and 

h) constructing a new list of GUIDs based on 
said renumbered physical identifiers of step f). 

A method as described in Claim 1 wherein each 
GUID is a persistent multi-bit value comprising a 
vendor code portion and a chip series code portion. 

A method as described in Claim 1 wherein said step 
a) is performed in response to a local bus reset and 
comprises the steps of: 

a1 ) receiving from said local bus an indication 
of the number of devices of said local bus; 
a2) starting with physical identifier zero and in- 
crementing to a last physical identifier corre- 



18 



BNSDOCID: <EP 0932275A2_I_> 



35 



EP 0 932 275 A2 



36 



sponding to said n umber of devices of said local 
bus, forwarding requests to said devices of said 
local bus individually requesting their GUIDs; 
a3) recording into said list of GUIDs any GUIDs 
returned from said devices of said local bus, 
said GUIDs recorded into positions said list of 
GUIDs based on their corresponding physical 
identifier values; and 

a4) storing said list of GUIDs into a computer 
readable memory unit. 

6. A method of providing device identification to ac- 
cess information within a network, said method 
comprising the steps of: 

a) constructing a list of global unique identifiers 
(GUIDs) wherein each GUID identifies a unique 
device of said network and wherein said con- 
structing orders GUIDs within said list of GUIDs 
according to their associated physical identifier 
values, wherein said physical identifier values 
are assigned by a local bus of said network; 

b) receiving a request originating from an ap- 
plication program to determine topology infor- 
mation corresponding to a device of said net- 
work wherein said request includes a first GUI D 
corresponding to said device; 

c) using said list of GUIDs to determine a first 
index value corresponding to a position of said 
first GUID within said list of GUIDs; and 

d) referencing a topology map data structure 
with said first index value to obtain said topol- 
ogy information, wherein said topology map da- 
ta structure is organized based on physical 
identifiers. 

7. A method as described in Claim 6 further compris- 
ing the step of e) communicating said topology in- 
formation to said application program and wherein 
said network is a network of the home audio/visual 
initiative (HAVI) architecture and wherein said local 
bus is of the IEEE 1 394 standard. 

8. A method as described in Claim 6 further compris- 
ing the steps of: 

f) in response to a local bus reset, renumbering 
physical identifiers of devices of said network 
that are coupled to said local bus; 

g) rebuilding said topology map data structure 
based on renumbered physical identifiers of 
step f); and 

h) constructing a new list of GUIDs based on 
said renumbered physical identifiers of step f). 

9. A method as described in Claim 6 wherein each 
GUID is a persistent multi-bit value comprising a 
vendor code portion and a chip series code portion. 



10. A method as described in Claim 6 wherein said step 
a) is performed in response to a local bus reset and 
comprises the steps of: 

5 a1) receiving from said local bus an indication 

of the number of devices of said local bus; 
a2) starling with physical identifier zero and in- 
crementing to a last physical identifier corre- 
sponding to said number of devices of said local 

w bus, forwarding requests to said devices of said 

local bus individually requesting their GUIDs; 
a3) recording into said list of GUIDs any GUIDs 
returned from said devices of said local bus, 
said GUIDs recorded into positions said list of 

is GUIDs based on their corresponding physical 

identifier values; and 

a4) storing said list of GUIDs into a computer 
readable memory unit. 

20 11. A method of providing device identification within a 
network, said method comprising the steps of: 

a) constructing a list of global unique identifiers 
(GUIDs) wherein each GUID is persistent and 

25 identifies a unique device of said network and 

wherein said constructing orders GUIDs within 
said list of GUIDs according to their associated 
physical identifier values, wherein said physical 
identifier values are assigned by a local bus of 
said network; 

b) receiving a request originating from an ap- 
plication program to communicate with a device 
of said network wherein said request includes 
an identifier corresponding to said device: 

c) translating said identifier into a first GUID 
corresponding to said device; 

d) using said list of GUIDs to determine a first 
index value corresponding to a position of said 
first GUID within said list of GUIDs wherein said 
first index value is a first physical identifier; and 

e) issuing a communication to said device over 
said local bus using said first physical identifier, 
wherein said communication corresponds to 
said application program request. 

12. A method as described in Claim 11 wherein said 
network is a network of the home audio/visual initi- 
ative (HAVI) architecture and wherein said local bus 
is of the IEEE 1394 standard. 

13. A method as described in Claim 11 further compris- 
ing the steps of: 

f) in response to a local bus reset, renumbering 
physical identifiers of devices of said network 
that are coupled to said local bus; and 

g) constructing a new list of GUIDs based on 
said renumbered physical identifiers of step f). 
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14. A method as described in Claim 11 wherein each 
GUID is a multi-bit value comprising a vendor code 
portion and a chip series code portion. 

15. A method as described in Claim 11 wherein said 
step a) is performed in response to a local bus reset 
and comprises the steps of: 

a1) receiving from said local bus an indication 
of the number of devices of said local bus; 
a2) starting with physical identifier zero and in- 
crementing to a last physical identifier corre- 
sponding to said number of devices of said local 
bus, forwarding requests to said devices of said 
local bus individually requesting their GUIDs; 
a3) recording into said list of GUIDs any GUIDs 
returned from said devices ol said local bus, 
said GUIDs recorded into positions said list of 
GUIDs based on their corresponding physical 
identifier values; and 

a4) storing said list of GUIDs into a computer 
readable memory unit. 

16. An electronic system having a processor, an inte- 
rnal bus and a computer readable memory unit, said 
system coupled to an IEEE 1394 local bus, wherein 
said memory unit having instructions stored therein 
that implement a method of providing device iden- 
tification to access information within a network, 
said method comprising the steps of: 

a) constructing a list of global unique identifiers 
(GUIDs) wherein each GUID is persistent and 
identifies a unique device of said network and 
wherein said constructing orders GUIDs within 
said list of GUIDs according to their associated 
physical identifier values, wherein said physical 
identifier values are assigned by a local bus of 
said network; 

b) receiving a request originating from an ap- 
plication program to determine information cor- 
responding to a device of said network wherein 
said request includes a first GUID correspond- 
ing to said device; 

c) using said list of GUIDs to determine a first 
index value corresponding to a position of said 
first GUID within said list of GUIDs; and 

d) referencing a map data structure with said 
first index value to obtain said information said 
wherein said map data structure is organized 
based on physical identifiers. 

17. An electronic system as described in Claim 16 
wherein said method further comprises the step of 
e) communicating said information to said applica- 
tion program and wherein said network is a network 
of the home audio/visual initiative (HAVI) architec- 
ture and wherein said local bus is of the IEEE 1394 



standard. 

18. An electronic system as described in Claim 16 
wherein said method lurther comprises the steps of: 

s 

f) in response to a local bus reset, renumbering 
physical identifiers of devices of said network 
that are coupled to said local bus; 

g) rebuilding said map data structure based on 
10 renumbered physical identifiers of step f); and 

h) constructing a new list of GUIDs based on 
said renumbered physical identifiers of step f). 

19. An electronic system as described in Claim 16 
is wherein each GUID is a multi-bit value comprising 

a vendor code portion and a chip series code por- 
tion. 

20. An electronic system as described in Claim 16 
20 wherein said step a) of said method is performed in 

response to a local bus reset and comprises the 
steps of: 

a1 ) receiving from said local bus an indication 
25 of the number of devices of said local bus; 

a2) starting with physical identifier zero and in- 
crementing to a last physical identifier corre- 
sponding to said number of devices of said local 
bus, forwarding requests to said devices of said 
30 local bus individually requesting their GUIDs; 

a3) recording into said list of GUIDs any GUIDs 
returned from said devices of said local bus, 
said GUIDs recorded into positions said list of 
GUIDs based on their corresponding physical 
35 identifier values; and 

a4) storing said list of GUIDs into said computer 
readable memory unit. 

21. An apparatus for providing device identification to 
40 access information within a network, said apparatus 

comprising: 

a) means for constructing a list of global unique 
identifiers (GUIDs), 

45 wherein each GUID is persistent and identifies 

a unique device of said network, by ordering 
GUIDs within said list of GUIDs according to 
their associated physical identifier values, 
wherein said physical identifier values are as- 

so signed by a local bus of said network; 

b) means for receiving a request originating 
from an application program to determine infor- 
mation corresponding to a device of said net- 
work wherein said request includes a first GUID 

55 corresponding to said device; 

c) means for using said list of GUIDs to deter- 
mine a first index value corresponding to a po- 
sition of said first GUID within said list of GUIDs; 
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and 

d) means for referencing a map data structure 
with said first index value to obtain said infor- 
mation said wherein said map data structure is 
organized based on physical identifiers. 5 

22. An apparatus as described in Claim 21 wherein said 
means for constructing is responsive to a local bus 
reset and comprises: 

10 

a1 ) means for receiving from said local bus an 
indication of the number of devices of said local 
bus; 

a2) means for starting with physical identifier 
zero and incrementing to a last physical identi- is 
tier corresponding to said number of devices of 
said local bus, forwarding requests to said de- 
vices of said local bus individually requesting 
their GUIDs; 

a3) means for recording into said list of GUIDs 20 
any GUIDs returned from said devices of said 
local bus, said GUIDs recorded into positions 
said list of GUIDs based on their corresponding 
physical identifier values; and 

a4) means for storing said list of GUIDs into 2s 
said computer readable memory unit. 
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